FIG. 1 shows an exemplary network structure of an Evolved Universal Mobile Telecommunications System (E-UMTS) as a mobile communication system to which a related art and the present invention are applied. The E-UMTS system is a system that has evolved from the existing UMTS system, and its standardization work is currently being performed by the 3GPP standards organization. The E-UMTS system can also be referred to as a LTE (Long-Term Evolution) system.
The E-UMTS network can roughly be divided into an E-UTRAN and a Core Network (CN). The E-UTRAN generally comprises a terminal (i.e., User Equipment (UE)), a base station (i.e., eNode B), an Access Gateway (AG) that is located at an end of the E-UMTS network and connects with one or more external networks. The AG may be divided into a part for processing user traffic and a part for handling control traffic. Here, an AG for processing new user traffic and an AG for processing control traffic can be communicated with each other by using a new interface. One eNode B may have one or more cells. An interface for transmitting the user traffic or the control traffic may be used among the eNode Bs. The CN may comprise an AG, nodes for user registration of other UEs, and the like. An interface may be used to distinguish the E-UTRAN and the CN from each other.
The various layers of the radio interface protocol between the mobile terminal and the network may be divided into a layer 1 (L1), a layer 2 (L2) and a layer 3 (L3), based upon the lower three layers of the Open System Interconnection (OSI) standard model that is well-known in the field of communications systems. Among these layers, Layer 1 (L1), namely, the physical layer, provides an information transfer service to an upper layer by using a physical channel, while a Radio Resource Control (RRC) layer located in the lowermost portion of the Layer 3 (L3) performs the function of controlling radio resources between the terminal and the network. To do so, the RRC layer exchanges RRC messages between the terminal and the network. The RRC layer may be located by being distributed in network nodes such as the eNode B, the AG, and the like, or may be located only in the eNode B or the AG.
FIG. 2 shows exemplary control plane architecture of a radio interface protocol between a terminal and a UTRAN (UMTS Terrestrial Radio Access Network) according to the 3GPP radio access network standard. The radio interface protocol as shown in FIG. 2 is horizontally comprised of a physical layer, a data link layer, and a network layer, and vertically comprised of a user plane for transmitting user data and a control plane for transferring control signaling. The protocol layer in FIG. 2 may be divided into L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3) based upon the lower three layers of the Open System Interconnection (OSI) standards model that is widely known in the field of communication systems.
Hereinafter, particular layers of the radio protocol control plane of FIG. 2 and of the radio protocol user plane of FIG. 3 will be described below.
The physical layer (Layer 1) uses a physical channel to provide an information transfer service to a higher layer. The physical layer is connected with a medium access control (MAC) layer located thereabove via a transport channel, and data is transferred between the physical layer and the MAC layer via the transport channel. Also, between respectively different physical layers, namely, between the respective physical layers of the transmitting side (transmitter) and the receiving side (receiver), data is transferred via a physical channel.
The Medium Access Control (MAC) layer of Layer 2 provides services to a radio link control (RLC) layer (which is a higher layer) via a logical channel. The RLC layer of Layer 2 supports the transmission of data with reliability. It should be noted that if the RLC functions are implemented in and performed by the MAC layer, the RLC layer itself may not need to exist. The PDCP layer of Layer 2 performs a header compression function that reduces unnecessary control information such that data being transmitted by employing Internet Protocol (IP) packets, such as IPv4 or IPv6, can be efficiently sent over a radio interface that has a relatively small bandwidth.
The Radio Resource Control (RRC) layer located at the lowermost portion of Layer 3 is only defined in the control plane, and handles the control of logical channels, transport channels, and physical channels with respect to the configuration, reconfiguration and release of radio bearers (RB). Here, the RB refers to a service that is provided by Layer 2 for data transfer between the mobile terminal and the UTRAN.
FIG. 4 is an exemplary view showing a detailed embodiment of HARQ applied to a downlink physical layer of a radio packet communication system. As shown in FIG. 4, eNode B decides a UE to receive a packet and a format of packet (coding rate, modulation method, data amount, and the like) to be transmitted to the UE. The eNode B then informs the UE of such information via the PDCCH, and thereafter transmits the corresponding data packet through a Physical Downlink Shared Channel (PDSCH) at an associated time. Thus, the UE can receive the information transmitted via the PDCCH so as to be known of the format of the packet to be transmitted to it and the packet transmission time, and also receive the corresponding packet via the PDSCH. After receiving the packet, the UE decodes the packet data. In case of a successful decoding, the UE transmits an ACK signal to the eNode B. The eNode B receiving the ACK signal may sense that the packet has successfully been received, thus to perform the next packet transmission. In case of an unsuccessful decoding, the UE transmits a NACK signal to the eNode B. The eNode B receiving the NACK signal may sense that the packet has unsuccessfully been received by the UE and accordingly retransmits the same data packet in the same format or a new format at an appropriate time. Here, the UE may combine the retransmitted packet with a packet which was received but failed to be decoded in various ways so as to attempt the decoding again.
In general, during a HARQ operation processing, a data retransmission of a transmitting side is based on feedback information transmitted from a receiving side. Namely, the transmitting side performs data retransmission when a HARQ NACK is received from the receiving side, and the transmitting side prepares to send next (or new) data when a HARQ ACK is received from the receiving side. Here, the transmission of next data is performed when the next data that has to be transmitted is still existed in a buffer of the transmitting side and when a radio resource is allocated for such data transmission.
As explained above, the receiving side has to send a proper feedback to the transmitting side during the HARQ operation. However, in contrast to data transmission of other upper channels, a HARQ ACK/NACK signal contains simple content (i.e., Yes or No), and there is no additional error protection for transmitting the HARQ ACK/NACK signal in current technology. Therefore, transmission errors can be easily happened while the HARQ operation is performed. For example, the receiving side may send an ACK message to the transmitting side, but the transmitting side may receive or treat it as a NACK message, and vice versa. Because of these errors, an optimized HARQ operation can not be performed in current technology.
In case that the receiving side sends a HARQ NACK to the transmitting side, there is a NACK-to-ACK error if the transmitting side receives it as a HARQ ACK. In such situation, the receiving side still waits to receive a retransmission of data, whereas the transmitting side sends a new data instead of retransmitting of the data.
In case that the receiving side sends a HARQ ACK to the transmitting side, there is an ACK-to-NACK error if the transmitting side receives it as a HARQ NACK. In such situation, the transmitting side performs a retransmission of data, and the receiving side receives a duplicated data from the transmitting side, thereby wasting an unnecessary radio resource(s).
Therefore, in a related art, there is no effective HARQ operation method that can minimize data loss due to these kinds of errors.